JBossがGroovyサポートとJSF強化を伴ってSeam 2.0をリリース

• WebServices(source) - Webサービスは会話的なものでありまたSeamコンポーネントとサービスを活用できる
• Groovy(source) - SeamコンポーネントはGroovyで記載することができる
• ホットデプロイ(source) - 開発モードでSeamは全体的なWARかEARを再デプロイする必要なしにコンポーネント定義をホットデプロイすることが可能
• Eclipseサポート - JBossToolsのSeam 2はプロジェクトウィザード、テストの統合、EL上での自動完結、ビューページのヴィジュアル編集等を搭載している
• JSFへの非依存性 - SeamがJSFから分離されたので他のWebフレームワークとより使いやすくなっている。実験的なGWT統合(source)が、これがどのように動作するか示すように原型化されている
• JSF 1.2サポート - SeamはデフォルトのJSF実装のようにマイフェースからJSF RIに変更した
• JBoss EL(source) - Seamはパラメータ化されたJBoss ELサポート、非JavaBeanプロパティとプロジェクション用のサポート
• Maven(source) - Seamが所有している依存性はMaven内で管理されている。Seam用のMavenリポジトリも有効。
• インテグレーション - インテグレーションがQuartz、JFreeChart、Hibernate Search、iTextのような人気なプロジェクト用にも有効になった

InfoQはこのリリースに関して議論するため、プロジェクトリーダーのGavin King氏と対談した。そして私たちはよりよいフレームワークにした2.0について、1.0バージョンから得た教訓とは何か尋ねた。

1.0で犯した最大のミスとは、

(1)JSF、EJB3、JTAで環境を想定するためにSeamを認可し、開発したこと。間違いなくこれらは全て人気なテクノロジーなのだが、それでもまだ他の環境でSeamを使用したいと思う人々がいてそういう人たちがその実装を始めるよう推し進めたのです。

(2)私たちの内蔵コンポーネントライブラリがどんなに大きく成長するか認識していなかったことです。以前のバージョンでは全ての内蔵コンポーネントを単純にもorg.jboss.seam.core.に全て投げました。Seam2では完全にパッケージ構造を再構築しなくてはならかったのです。

さて、私はここで考えるべき重要なことが二つあると思うのです。

(1)ユーザーインターフェースを宣言的に、それともプログラム的に定義するのどちらを好むでしょうか？

(2)クライアント側で機能がどのくらい実際に実行できるのでしょうか？

どの程度タイプセーフでいたいかという問題もあります。

これらの疑問はほとんど直交なのです。例えばGWTはタイプセーフでプログラム的でクライアント側のアプローチを提供します。一方Wicketはタイプセーフでプログラム的でサーバ側のアプローチを提供します。

JSFはいくらかタイプセーフの宣言型でサーバ側のアプローチを提供します。またそれには、必要なときにはプログラム的モードで働けるオプションがついてきます。それぞれのアプローチには利点と不利点がもちろんありますが、下記になぜJSFアプローチが素晴らしいかという理由を書いています。

一つ目に、私はユーザーインターフェースを宣言型の言語内で定義するのをはるかに好みます。ユーザーインターフェースは生まれつき階級型でコードのストラクチャーがそれを反映するようにしたいです。私はSwingスタイルのコードを使用してユーザーインターフェースを作って心地よく感じた事はありません。 この種のコードはいつも醜く保持するのが困難なものなのです。それは少しDOMツリーを通ってXMLを解析するJavaコードみたいです。そこには基礎的な構造の未結合が存在しているのです。

もちろんインターフェースの動的部分にはプログラム的操作は実用的です。しかしこれは確実に常識なケースではありません。ほとんどのユーザーインター フェースは個々のコントロールのレベル以外では極端に静的なのです。そしてもちろんJSFはブラウザのDOMと一緒に動作するJavaScriptコードの記述に戻ることもできるのです（最近ではJSFコンポーネントツリーへのクライアント側でのアクセスを可能にするJSF実装を作るのが可能ですが、私たちはまだそこに辿り着いていません。）。

二つ目に私はより多くのステートとクライアント側でのアプリケーションロジックをより多く実行すると開発労力をより削減できる、という考え方に同意していません。単にサーバー側でのみ効率的に処理が可能であるという懸念がありすぎるのです。持続性、セキュリティ、データレベル一致性等です。もしアプリケーションコードをクライアント側に持ってくると、ステートレスサービス層、データトランスファーオブジェクト、きめの細かいデータのマニュアルフェッチ、変更点の統合を伴って3、4年前の状態に戻ってしまうことになるのです。ステートフルのコンポーネントを採用し、対話スコープの持続性コンテキスト、つまりは サーバー側のテクノロジーを採用することによって、私たちはこの痛々しいプログラミングモデルから逃れたのです。

RichFacesとSeamを用いて非同期でのフェッチデータ、インタラクティブにビューをアップデートし、非同期にユーザーインタラクションに返答し、インタラクティブに変更を適用する、また全て明確な楽観的処理内で余分で騒々しいボイラープレートなしに、ユーザーインターフェースを作ることができるのです。もちろんJSFとRichFacesを学ぶのには他のアプローチよりも多少労力がかかります。しかしながら長い目でみるとその努力は報われるものなのです。

今日のJSFの基本的なアプローチにおいて一番の弱点はめったにコメントされていません。ビューをモデルに統合するためのELの使用におけるタイプセーフの欠落です。私の理想的な環境はユーザーインターフェースの定義用のタイプセーフで宣言型の言語をサポートするものとなるでしょう。あいにくJavaはそのようなDSLを生成する本当の意味でのサポートがありません。残念です。

Web BeansにはSeamから得たアイディアが盛り込まれています。

• コンテキスト的コンポーネント
• 会話
• ”優先的な”規則を介したコンポーネントオーバードライブ
• Java EEを伴う”深い”統合
• アノテーション統合ベースのインターセプター統合
• イベント告知

一方、Guiceからはアノテーション統合ベースの依存性インジェクションのアイディアを盗み、これには広範囲で影響力のある結論をもたらしました。

Web Beansは”強力なタイピングを伴う疎結合”を強調する、とてもユニークなプログラミングモデルにこれらのアイディア全てを混入します。下記の事項を利用してとても緩い疎結合のアプリケーションを完成することができます。

• クライアントとサーバーライフサイクルを減結合するコンテキスト的なライフサイクルマネジメント（まるでサービスかのように相互作用するステートフルコンポーネント）
• クライアントとサーバ実装を減結合するためのデプロイタイムコンポーネントオーバードライブ
• 消費者からメッセージプロデューサーを減結合するイベント告知
• 分野横断的な技術的懸念を減結合するインターセプター

全てはタイプセーフを犠牲にすることなく成り立っていて、全てはタイプセーフアノテーションを介して行われているのです。もちろんランタイム時にあなたを襲ってくるトリックは隠されていません。

総合的にWeb BeansはSeamの様式の上に成り立っていますが、それはよりさらに素晴らしいものだと思っています。私は素晴らしいエキスパートグループに恵まれて光栄です。

最後に私たちはKing氏に新たなwikiで動いているin.relation.to(サイト・英語)を開発するのに、Seamを使うことによってフレームワークのホールを発見することに繋がったかどうか尋ねた。

バグをいくつかとマイナーな制限をいくつか見つけました。しかしながらWikiが持っている一番大きな影響力はSeam用のプラグインアーキテクチャの開発のために私たちを奮い立たせたところにあるのです。